Today, there are service providers providing services in networks implemented as Virtual Private Networks (VPN) which are using links and routers of the existing networks. Such a VPN provides the appearance of a network dedicated to each customer of a service provider. In terms of security, each VPN is totally isolated from other. VPNs are of a particular importance to service providers insofar as these VPNS can be created within a single physical network to provide services to multiple customers in a transparent way.
Traditional Layer 2 VPNs are based on Layer 2 overlays over a shared network. Customer sites are interconnected via Layer 2 Virtual Circuits (Frame Relay or ATM Virtual Circuits). For any two customer devices to communicate, the Service Provider must establish one or several Layer 2 Virtual Circuits between these two customer devices.
Other VPNs are based on the MPLS (Multi Protocol Label Switching) protocol which is an IP technology defining the notions of PE (Provider Edge) devices, P (Provider) devices and CE (Customer Edge) devices. In a network using MPLS, a CE automatically has access to all CEs connected to the same PE or to any other CE attached to a PE device within the same network. The CEs are usually located on a customer premise and provide access to the shared network. MPLS technology allows the physical network to provide several VPNs to a plurality of companies sharing the physical infrastructure made up by the set of PE and P devices.
MPLS defines the use of Label Swapping technology within the network. For each customer flow, the PE devices associate a physical path across the network. This physical path is defined as a set of labels that are swapped by the P devices, along the path between the source to the destination of the packet.
For all types of Virtual Private Networks (VPN), it is mandatory to provide a precise measurement of the customer traffic transported by the shared physical network infrastructure. This measurement capability allows Service Providers to offer usage based billing in order to charge VPN customers based on the network resources they effectively use. Each packet transiting across the network must be paid for according to the real “route” followed by the packet. This determines the resources consumed by the packet across the shared physical network infrastructure. Global Service Providers face the complexity of fairly reflecting to their customers the diversity of the costs associated to their worldwide infrastructure based on what these customers effectively use.
Within an MPLS environment, such a measurement of the customers traffic flows is a challenge for Service Providers as MPLS brings an any-to-any capability to Virtual Private Networks when contrasted to traditional VPNs based on Layer 2 mechanisms. For example, by attaching a CE device to a PE, this CE device immediately obtains access to all other CE devices belonging to the same VPN that are attached to the same PE or to any other PE within the network. Although the any-to-any capability brings additional flexibility and scalability to MPLS based VPNs, country specificities as well as the variety of communication media being used make the problem much more complex in MPLS based VPNs (as contrasted with traditional VPNs) inasmuch as measurements based upon virtual circuits used in layer 2 mechanisms are not available.
Within each PE device, a dedicated routing table per VPN is used as soon as a CE belonging to this VPN is attaching to the PE. As P devices never attach a CE device, they do not contain any Routing Table associated to a VPN. In fact, P devices are not concerned with VPNs, they only behave as Label Swapping devices. The VPN dedicated routing table within a PE device is called a VRF (Virtual Routing and Forwarding instance). VRFs ensure that only those customer sites (with CE devices) that belong to the same VPN can communicate.
In a global service provider environment, the vast majority of customers served via Virtual Private Networks are not themselves truly global customers. Frequently, these customers have a large presence within one (or several) countries, with some presence dispersed in the rest of the world. As an example, a French company has in general a very large coverage (Customer Edge—CE devices) in France, a significant coverage in other countries in Europe, but a much less significant coverage outside of Europe. Charging such customers with a flat rate model is certainly not appropriate. Further, customer patterns are very likely to change across time, and Service Providers that cannot charge a customer on a per-usage basis are facing the risk of either being not competitive (not selected by potential customers), or not capable of controlling their costs (under charging or over charging their customers).
Traditionally, for MPLS based VPNs, the measurement problem is solved by routing the customer traffic to hub devices before getting out of a billing zone. The hub can be a customer owned router (functioning as a CE device), or is optionally provided by the Service Provider. This Hub provides a “bridge” between different billing zones. By measuring, for example at a layer 2 (or layer 1) level, on a per MPLS VPN basis, the traffic flowing across these Hubs, the amount of the customer traffic flowing between zones for each VPN can easily be determined and billing performed accordingly. While this solution does work, the costs associated to the Hub equipment may be prohibitive in a large service provider environment. Such a solution in fact requires dedicated equipment (a Router for example) for each VPN since for security reasons, the VPNs must be totally isolated in terms of devices routing tables. Because a CE device is an IP router (not MPLS enabled by definition), the connections between a PE and a CE has to be dedicated to a single VPN customer. Because traffic flowing between billing zones is potentially high, the links used by such connections are high speed links and require high performance PE and CE devices. Further, as a single PE to CE connection is defined over these links, the benefits of statistical multiplexing multiple connections ride over a link cannot be achieved.
Another set of solutions that can be used to solve the problems addressed in this application are solutions based on products such as Cisco's NetFlow or Cisco's BGP Policy Accounting. Solutions of this type are provided via software extensions within network devices (Routers in the MPLS case). These extensions measure the traffic flowing across a router and maintain the measurement data.
One or several Collecting devices (network appliances such as a Workstation) in the network asynchronously collect and aggregate this measurement information maintained by the network routers. Then, the aggregated information is analyzed off-line by a Service Provider's billing application.
Unfortunately, solutions based on these concepts are very resource intensive in terms of both processing resources (within the routers but also within the Collecting Devices) and in terms of traffic overhead because measured information must be gathered from the Collecting Devices from the network Routers. Further, such solutions are proprietary and not standardized and thus are not available on all types of platforms used for an MPLS network.